Programmable automation controllers (PACs) and their associated control programming are at the heart of modern industrial automation systems. These controllers interact with field devices on the plant floor to carry out controlled processes relating to such objectives as manufacture of a product, movement of material through a system, and other such processes. The controllers typically exchange data with the field devices using native hardwired I/O or via a plant network such as Ethernet, Data Highway Plus, Devicenet, or the like. The controller receives any combination of digital or analog signals from the field devices indicating a current state of the devices (e.g., temperature, position, part presence or absence, fluid level, etc.) , and executes a control program that performs automated decision-making for the process based on the received signals. The controller then outputs appropriate digital and/or analog control signaling to the field devices in accordance with the decisions made by the control program. These outputs can include component actuation signals, temperature or position control signals, commands to a machining or material handling robot, and the like.
The control program executed by the controller can comprise any conceivable type of code used to process input signals read into the controller and to control output signals from the controller, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, and the like. To simplify program development and to mitigate repetitive coding of commonly used functionality, the control program often includes or interacts with one or more functional modules, which are modular portions of code having predefined interfaces and functionality. These modules can interface with the control program through predefined inputs and outputs and perform data processing in accordance with one or more functions coded into the module. A module can represent a common control process or piece of equipment (e.g., a sequencing module, a motor control module, a material transfer module, a PID module, etc.), and can be deployed in any suitable controller to facilitate control processing per the module's designed functionality. Inputs, outputs, parameters, modes, statuses, and behaviors can be predefined for each module in accordance with its desired functionality.
Modules often comprise a number of cross-cutting concerns, or aspects, which are distinct features whose functionality affects several other parts of the module. Because of the programmatic interdependencies between aspects comprising a module, aspects typically cannot be added or modified without writing customized code establishing the interactions between the new or modified aspects and other portions of the module. For a new module, the interactions between the aspects must be defined during development. When modifying an existing module to add or modify aspects in accordance with the needs of a particular application, new code must be written to properly integrate the new or modified aspects with the preexisting aspects comprising the module. Thus, although a given aspect represents a definable area of functionality, the aspect cannot be added, removed, or modified in a clean, modular fashion.
Although modules are often designed to be used flexibly in a wide range of control applications, it is sometimes necessary to design a module tailored to the needs of a particular application. This sometimes involves programming a module from the ground up to meet the requirements of the application. In other instances, it may be preferable to modify or replace a selected subset of an existing module's functionality or aspects to suit the needs of a given system.
Because of the programmatic interdependencies between the aspects that make up a module, it is usually necessary write new custom code establishing the interactions between the new or altered aspects and other aspects comprising the module. In order to simplify module development, developers sometimes rely on reusable functional components that can be integrated into any given module. However, given the structural idiosyncrasies inherent in modules that were designed and written under different circumstances and to different specifications, as well as the interdependent nature of the cross-cutting concerns described above, even these reusable components require custom code to be written in order to properly adapt the components for operation within a particular module and to link the aspects within the module. Consequently, development or alteration of modules entails considerable investment of time and effort, even when needed functionality is readily available as a reusable component.
In view of the design inefficiencies discussed above, there is a need for an aspect-based module development architecture that allows functions compliant with the architecture to be easily and quickly combined to create a customized module without the need to write new code integrating the functions.